home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0399 / 275 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  4.2 KB
  1. Date: Thu, 2 Jun 94 17:17 BST-1
  2. From: Andre Willey <andre@cix.compulink.co.uk>
  3. Subject: Re: Shortcut Manager
  4. To: gem-list@world.std.com
  5. Message-Id: <memo.274025@cix.compulink.co.uk>
  6. Precedence: bulk
  7.  
  8.  
  9.  
  10. Right, answering a few points in one go. (and please could you try doing the
  11. same, to cut down on the bandwidth here?)
  12.  
  13.  
  14.  
  15. In <9406021115.AA07464=avg@mijt.cwi.nl>, Annius.Groenink@cwi.nl wrote:
  16.  
  17.   > But I insist that we design an elaborate standard for dividing the
  18.   > shortcuts into groups for different applications or different classes
  19.   > of applications, as opposed to just defining all shortcuts for all
  20.   > applications 
  21.  
  22. I disagree. The whole point is to keep the thing as *simple* as possible:
  23. define general operations, and if an application doesn't support that
  24. operation, don't load the shortcut. e.g. your example of DTP not needing
  25. the explicit codes for Bold, Italic, etc. Fine, so DTP programs don't load
  26. them. Equally, if we have a code for 'Font selector', that might not be
  27. required by a simple text editor, but a DTP program should support it.
  28.  
  29. Each program already *knows* what kind of application it is, and should
  30. understand which shortcuts it can viably support, and which don't apply to
  31. it.
  32.  
  33.  
  34.  
  35. In <9406021218.AA07652=avg@mijt.cwi.nl>, Annius.Groenink@cwi.nl wrote:
  36.   
  37.   > Actually,  with the current easy of incorporating a resource
  38.   > in C  (Interface and RSH format)  I think all applications should
  39.   > protect their resources by including them into the binary. 
  40.   >  
  41.   > Who wants hacked versions of their software floating around? 
  42.  
  43. People in Germany who don't speak English, and vice versa? The RSC system
  44. does make basic translations a lot simpler.
  45.  
  46.  
  47.  
  48. In <9406021212.AA07620=avg@mijt.cwi.nl>, Annius.Groenink@cwi.nl wrote:
  49.  
  50.   > Let's continue as follows:  we'll talk about what exactly we want in
  51.   > the KEYBIND.INF file,  and what not.  Then after a few days,  based
  52.   > on the results of that discussion,  I will put forward a definition
  53.   > of the file's syntax
  54.  
  55. Oh, you will, will you...?
  56.  
  57.   > We will also define a preferred way of interpreting the file.  Then
  58.   > after I have submitted the prototype definition and semantics,  you
  59.   > guys pull it down again (in a constructive sense).  How does that
  60.   > sound? 
  61.  
  62. Oh, am I allowed to see what you have decided to do to my proposals at that
  63. stage, then? That's very generous of you.
  64.  
  65. On the other hand, we could all discuss it here, then Ofir and I can make
  66. any agreed revisions and put it into his amended proposal for the group.
  67.  
  68.   > In a very simple formalism.  I'm convinced that we need to separate
  69.   > codes into default sections,  class dedicated sections and
  70.   > application-specific codes. 
  71.  
  72. I think I've covered that already. What we could do is to allocate
  73. blocks of numbers for very specific tasks, such as DTP, MIDI, etc.
  74. Would that make you happier? (e.g. 1000+ for DTP-oriented tasks, 2000+
  75. for MIDI, 3000+ for painting/photo/etc, 4000+ for Database, etc). Again
  76. I wanted to avoid making this too complex - if it's hell to work with, no
  77. one will bother.
  78.  
  79.   > I think we shouldn't use 'codes'.  Your formalism looks too much like
  80.   > ASSIGN.SYS,  which IMHO is hard to grab for a naive user (it is hard
  81.   > enough to understand for me!) 
  82.  
  83. Hence the comments at the end of each line, which could be in any language
  84. (or several, come to that). Parsing text is a waste of time for a program,
  85. and rather annoying for non-English speakers, I guess. Let's keep it plain
  86. and simple, and avoid creating something over-complex just for the hell of
  87. it. Otherwise we might as well end up writing the thing in COBOL...
  88.  
  89. The whole *idea* was to generate a file along the lines of ASSIGN.SYS, but
  90. with multi-language (optional) comments to allow users to change it if they
  91. want - or, as others have said, just use an editor.
  92.  
  93.   > Sorry,  I'm getting tired. 
  94.  
  95. Hmm, perhaps you should go and lie down for a bit, then?
  96.  
  97. Andre
  98.  
  99.  +------------------------------------+-------------------------------+
  100.  |            Andre Willey            |  Cygnus Software Development  |
  101.  |  Email: andre@cix.compulink.co.uk  |  Sutton Coldfield -- England  |
  102.  |   or: ...{mcsun}!uknet!cix!andre   |  Tel:  (UK/+44) 021 308 5251  |
  103.  +------------------------------------+-------------------------------+
  104.